DevOps Overview BTech CSE Sem V · UPES Dehradun
Unit I · Lecture 5 · Final Lecture of Unit I

Agile Manifesto, Part 2
Customer Collaboration · Responding to Change

The final two Agile values — followed by a complete Unit I recap,
Q&A, and a preview of Unit II.

COURSE
DevOps Overview
UNIT
I of IV
LECTURE
5 of 5
PREV. LECTURE
Individuals & Working SW

Dr. Mohsin Furkh Dar  ·  School of Computer Science, UPES Dehradun

Overview

What We Cover Today

🔁 Recap
Quick recap of Values 1 & 2 from Lecture 4.
🤝 Value 3: Customer Collaboration
Why ongoing partnership beats fixed contracts — and what it looks like in practice.
🔄 Value 4: Responding to Change
Why plans are a starting point, and how Agile makes late change cheap.
📊 Cost-of-Change Curve
The single chart that explains why Agile exists.
🗂️ Unit I — Full Recap
A guided tour back through Lectures 1–5, tying every concept together.
❓ Q&A + Unit II Preview
Open discussion, sample exam-style questions, and what's coming in Unit II.
Recap — Lecture 4

Where We Left Off

Value 1 — Individuals & Interactions over processes & tools: People, conversation, and self-organising teams produce better outcomes than rigid procedures. Tools support people; they don't replace judgment.
Value 2 — Working software over comprehensive documentation: Running, tested code is the only artifact that cannot fake its own correctness. Documentation should serve the team, not satisfy a checklist.
③④
Today's focus
Customer collaboration over contract negotiation and responding to change over following a plan — the two values about how Agile relates to the customer and to uncertainty.
01

Customer Collaboration

Customer collaboration over contract negotiation
Value 3 — Origins

Why "Collaboration" Replaced "Negotiation"

Traditional contracts treat software development as an adversarial transaction: the customer specifies everything upfront, the vendor commits to a fixed price and date, and any deviation becomes a negotiation — often a dispute — about who is at fault and who pays.
  • The fixed-contract trap: A contract written before any software exists is a contract written with the least information either party will ever have. Yet it is treated as binding for the life of the project.
  • Misaligned incentives: Once signed, the vendor is incentivised to deliver exactly what's written — even if better options become obvious — because deviation creates legal and financial risk.
  • The customer is the domain expert: Only the customer truly understands their business context, and that understanding deepens as they see working software. Excluding them after sign-off wastes this expertise.
  • Manifesto's claim: Treat the customer as a collaborative partner throughout the project — not a stakeholder who appears only at the start (to sign) and the end (to accept or reject).
Value 3 — In Practice

Contract Negotiation vs Customer Collaboration

Dimension📜 Contract Negotiation🤝 Customer Collaboration
Relationship Buyer vs vendor — adversarial by structure Shared team working toward a common goal
Customer involvement Sign requirements at start, accept/reject at end Present at every sprint review — continuous input
When priorities change Formal change order — renegotiate scope/price/time Backlog reprioritised together — no renegotiation needed
Success defined by "Did we build what the contract said?" "Is the customer getting real value, sprint by sprint?"
Risk handling Risk allocated contractually — who "owns" the blame Risk surfaced and addressed together, early
Documentation role Legal artifact Primary reference for disputes Working agreement Defines collaboration terms, not fixed scope
Note: contracts still exist in Agile engagements — but well-written Agile contracts define how the team and customer will work together (cadence, ceremonies, change process) rather than locking in a fixed, unchangeable scope.
Value 3 — Mechanisms

How Customer Collaboration Actually Happens

👤 Product Owner role
A dedicated person represents the customer's interests daily — prioritising the backlog and answering questions in real time.
🖥️ Sprint reviews / demos
Every 1–4 weeks, the customer sees and interacts with real working software — not slides or documents.
📋 Living backlog
Customer reprioritises the backlog continuously based on what they've learned from previous sprints.
💬 Direct access
Developers can ask the customer clarifying questions directly — instead of waiting weeks for a formal response.
📈 Shared metrics
Burndown charts, velocity, and release plans are visible to the customer — no information asymmetry.
🎯 Shared definition of value
Team and customer jointly define what "valuable" means for this product — not imposed by either side alone.
02

Responding to Change

Responding to change over following a plan
Value 4 — Origins

Why Plans Are a Starting Point, Not a Destination

A project plan is a prediction made with the least information you'll ever have, about a future that hasn't happened yet. Treating it as immutable means optimising for "matching the prediction" instead of "achieving the actual goal."
  • Markets change: A competitor launches a new feature, a regulation changes, user behaviour shifts — none of this was knowable when the original plan was written months or years earlier.
  • Understanding deepens: The act of building software teaches the team things about the problem that were impossible to know in advance — "we now realise users actually need X, not Y."
  • "On plan" ≠ "successful": A project can hit every milestone in its original plan and still fail commercially, because the plan described the wrong thing.
  • Manifesto's claim: The ability to change direction — based on new information — is more valuable than the discipline of sticking to an outdated plan. This is a deliberate capability, not a failure to plan.
Value 4 — In Practice

Following a Plan vs Responding to Change

📐 Plan-Driven

  • Detailed project plan created before work begins — Gantt charts, fixed milestones
  • Success measured by adherence to the plan
  • New information treated as a "deviation" to be corrected
  • Schedule and scope are fixed; quality or team health absorb the pressure
  • Planning happens once, in detail, at the start
  • "We said we'd deliver X by date Y, so we will — even if X is no longer the right thing"

🔄 Change-Driven (Agile)

  • High-level roadmap exists, but detailed planning happens per sprint
  • Success measured by value delivered, given current information
  • New information treated as an input to replanning — expected and welcomed
  • Scope is the variable; date and quality are protected (timeboxing)
  • Planning happens continuously — every sprint planning session
  • "We learned X is no longer the priority — let's build Y instead, this sprint"
Value 4 — The Core Argument

The Cost-of-Change Curve

1×
Requirements
3×
Design
8×
Coding
20×
Testing
60–100×
Production
In Waterfall, a change found late costs dramatically more than the same change found early.
Agile's short sprints keep every change inside the "Requirements/Design" zone — even in week 20 of a project.
This is the single strongest argument for short feedback loops.
The insight: Agile doesn't make change "free" — it makes change early, by keeping the gap between "decision" and "feedback" as short as possible. Iteration is a mechanism for staying on the cheap end of this curve, permanently.
03

Unit I — Full Recap

From the Advent of Software Engineering
to the complete Agile Manifesto — five lectures, one story

Unit I — The Whole Story

Lectures 1–5 at a Glance

L1
Advent of SE & Waterfall
Software crisis of the 1960s → NATO 1968 coins "Software Engineering" → Royce's Waterfall model (1970): sequential phases, heavy documentation, late testing.
L2
Dev vs Ops & Agile (2001)
Waterfall's silos created the "Wall of Confusion" between Dev and Ops. Frustration with heavyweight process led 17 practitioners to write the Agile Manifesto at Snowbird, 2001.
L3
Agile vs Waterfall & Iteration
Structured six-dimension comparison; decision framework for choosing a methodology; Agile is both iterative (refine) and incremental (add value) via the sprint cycle.
L4
Values 1 & 2
Individuals & interactions over processes & tools — people and self-organising teams. Working software over documentation — Definition of Done as the real measure of progress.
L5
Values 3 & 4 (Today)
Customer collaboration over contract negotiation — ongoing partnership. Responding to change over following a plan — the cost-of-change curve explains why.
Unit I — Synthesis

How It All Connects

The thread running through Unit I: Every concept is a response to the same underlying tension — how much can be known in advance, and what should we do about the rest?
①
Waterfall's bet
Assume everything can be known upfront → invest heavily in planning and documentation → execute the plan precisely.
②
Where the bet failed
Requirements changed, integration surprised everyone late, and Dev/Ops silos meant feedback from production never reached planning.
③
Agile's counter-bet
Assume uncertainty is permanent → build short feedback loops → let working software and customer input continuously correct direction.
④
The four values, unified
People over process, software over docs, collaboration over contracts, adaptation over plans — all four reduce the gap between decision and feedback.
⑤
The open question
Agile fixed how development teams work. It didn't fix how code gets deployed and operated — that gap is exactly where Unit II begins.
Q&A — Discussion Prompts

Questions to Test Your Understanding

L1Why was the term "Software Engineering" deliberately provocative when coined in 1968?
Think about what it implied was missing from software development at the time.
L2How did Waterfall's structure directly cause the "Wall of Confusion" between Dev and Ops?
Consider how phase-gated handoffs create organisational incentives.
L3Give an example of a project where Waterfall would be the more defensible choice — and justify it.
Think about regulatory, contractual, or hardware-coupled constraints.
L4Explain why "the project is on schedule" and "the project is documented" are not evidence of progress in Agile.
Relate back to the Definition of Done.
L5Using the cost-of-change curve, explain why finding a requirements misunderstanding in Sprint 1 is dramatically cheaper than finding it in production.
Connect this to why short iterations exist at all.
Looking Ahead

Unit I Complete — What's Next in Unit II

Unit I — Completed

Traditional Development & Rise of Agile

  • Software Engineering origins & Waterfall
  • Dev vs Ops conflict & the Agile Manifesto
  • Agile vs Waterfall — structured comparison
  • Iterative, incremental development (sprints)
  • All four Agile Manifesto values, in depth
→
Unit II — Coming Next

Introduction to DevOps

  • What DevOps is — and what problem it solves
  • DevOps as the bridge across the Dev/Ops wall
  • Core DevOps practices: CI, CD, IaC, monitoring
  • The DevOps toolchain landscape
  • DevOps culture: CALMS framework
The connecting thread: Unit I established why teams need short feedback loops and adaptability. Unit II answers the practical question Agile left open: how do we extend that same speed and adaptability all the way into deployment, infrastructure, and operations?
DevOps Overview · Unit I Complete · Lecture 5 of 5  ·  Dr. Mohsin Furkh Dar  ·  UPES Dehradun · Summer 2026
← → or swipe